QUALITY OF SERVICE OF A FLIGHT MANAGEMENT SYSTEM

专利摘要:
There is disclosed a computer-implemented method in or for a flight management system or FMS, comprising the steps of receiving requests from clients; determining a correspondence between the requests and predefined unitary services executable by at least one server associated with said FMS; thread the determined unit services into one or more queues; determine a response time associated with each request; and notify at least one client of the response time to his request. Developments describe queue processing, priority management, the existence of packages, caching mechanisms, queuing interrupts, request queries, voting mechanisms, and more. Unit services in particular may be avionics services of the ATA type (acronym for "Air Transport Association"). Aspects of systems and software are described. 150 words
公开号:FR3030805A1
申请号:FR1402933
申请日:2014-12-19
公开日:2016-06-24
发明作者:Francois Coulmeau；Laurent Castet；Laurent Deweerdt；Frederic Sanchez
申请人:Thales SA；
IPC主号:

专利说明:

[0001] FIELD OF THE INVENTION The invention generally relates to methods and systems for the management of the flight of an aircraft, in particular as regards determination or prediction of trajectories. The invention particularly relates to embedded systems in avionics systems.
[0002] State of the art Each real-time avionics system is architected and developed to meet performance requirements in a defined user context (for example in terms of RAM, ROM, failure rate or reset, CPU load and Quality of Service or Functional QoS The embedded systems are qualified, with a demonstrated level of performance, for a given environment The interactions between embedded systems are defined a priori during the development of the architecture of the aircraft, and these embedded systems are developed and adjusted to strictly meet the needs identified.In a client-server perspective, according to which a set of so-called "CLIENT" systems make requests to one or more specific service provider systems says "SERVER" The technical problem of guaranteeing the said customers a certain level of quality of service, for example in accuracy and response time as expected by customers expect, and ensure the smooth operation of the entire architecture "N clients and M servers" as and when updates of different systems (ie managing variability and different development cycles). The evolutions of a system (client or server) must not give rise to a questioning of all connected systems. Moreover, in an embedded real-time environment, in which the subsystems have a different level of criticality, it is desirable to modify as little as possible the critical systems officiating as servers, taking into account the costs and the risks of degradation of said systems. These technical issues are currently unresolved and requalification is required to add any new system that wants to connect to an existing system. A new certification or recertification of the aircraft is usually required, resulting in substantial additional costs. In fact, these systemic aspects (involving revisions of the server architecture and their interfaces and therefore requalification costs) are currently constraining the evolution of aircraft operations. In practice, for example, if a customer needs a Quality of Service (QoS) of a certain level (such as an expected response time limit), and the server needs more time to perform its calculation, the consequence that follows is that the customer will have to wait. In some alternative configurations, the server may decide to cancel the client's request if the required calculation time is greater than the response time requested by the client. This type of configuration is however not acceptable in certain situations, in particular in the case of embedded real-time systems that require a response in the given time to ensure their proper operation. For example, particularly in the context of "open" architectures where a previously unknown number of clients connects asynchronously and randomly to a server with limited computing capacity, the existing solutions will, in the best case, reject too many queries, or in the worst case respond too often and / or too late, jeopardizing the overall architecture of the system. Prior art known approaches generally involve requalifying the equipment affected or impacted by a new connection (even with constant features), to check performance performance. Avionics architectures are therefore statically defined during the design of the aircraft system. The patent literature does not provide a satisfactory solution to the technical problem. For example, US 8832302 entitled "System and method for scheduling of network services" describes a system for ad hoc networks including service recognition mechanisms. This approach structured by services and not by data has limitations. There is an industrial need for processes and systems corresponding to flexible and adaptable architectures, in particular enabling the scalability of the different client and server systems independently, while guaranteeing the customers a guaranteed level of quality of service. . SUMMARY OF THE INVENTION There is disclosed a computer-implemented method in (eg, "built-in") and / or ("associated with") a flight management system or FMS, including the steps of receiving queries issued by clients; determining a correspondence between the requests and predefined unit services executable by at least one server associated with said FMS; thread the determined unit services into one or more queues; determine a response time associated with each request; and notify at least one client of the response time to his request. Developments describe queue processing, priority management, the existence of packages, caching mechanisms, queuing interrupts, request queries, voting mechanisms, and more. Unit services in particular may be avionics services of the ATA type (acronym for "Air Transport Association"). Aspects of systems and software are described.
[0003] According to one aspect of the method according to the invention, the service provider is segmented or separated or delimited into three sub-parts: a) the numerical computing core called "CORE", which offers unit computing services; b) a "SEP SERVER" for "Separated Server" comprising a "SERVER CORE" which is a request transcription layer of CLIENTS in the unitary services of the core and c) a "SERVER FRONT END" which is a dialogue layer with "CUSTOMERS", including the requests of the various customers (acceptance logic, priority, filtering ...).
[0004] According to one aspect of the invention, the server (the "SERVER FRONT END") will make it possible to decouple QoS management aspects for "CUSTOMERS" in an evolving environment while relying on a stable core "CORE" which basically supports the ability to manage any number of clients (limited only by available resources) while continuing to fulfill its core mission by meeting the associated performance requirements. In this way, the variability problems of CLIENTS are isolated from those concerning CORE. The robustness of CORE remains guaranteed since the code of management of the customers, and the variability of the interfaces is managed by the "SERVER FRONT END" and "SERVER CORE". In some embodiments, the aforementioned adaptive "SEP SERVER" system is configurable at startup ("at start time" in English) or even at runtime ("at runtime" in English, ie dynamic configuration at runtime ). For example, at startup, the system reads a configuration table that describes the topology of the customers present and the list of available "CORE" services, along with their characteristics. The "SEP SERVER" system then self-configures to reserve the necessary resources. According to one aspect of the invention, one embodiment of the method creates a "SEP SERVER" isolated from "CORE", and configures this ((SEP SERVER) by establishing i) the characteristics in terms of unit service quality of services offered by the "CORE" ii) the correspondence between the requests of the "CUSTOMERS" and the unitary services of the "CORE" capable of executing them; iii) the correspondence between the results of the 10 unitary services of CORE and the results expected by the client; iv) the scheduling of the requests of the different "CUSTOMERS" on the "CORE" or "CORE" able to treat them. Advantageously, an embodiment of the method according to the invention makes it possible to decouple the evolutions of the "CORE" service providers 15 and the "CLIENT" clients, which ensures the upward compatibility and the control of the requalification of all the systems . Advantageously, an embodiment of the method according to the invention makes it possible to retain the intrinsic performance of the "CORE" without having to know the outside customers a priori, while guaranteeing the customers in question a calculation result with the quality of service required. Advantageously, an embodiment of the method according to the invention makes it possible to set up mutualization mechanisms and / or functional caches on logging and optimization of calls to the core services. This aspect notably makes it possible to manage the obsolescence of the data of the cache to be determined versus the time of recalculation of the data. The concept of cache is all the more relevant when it comes to consulting large data or subset of large data (eg active FPLN and its associated trajectory for a Flight Management System or FMS or flight management system ) Advantageously, an embodiment of the method according to the invention, via the creation of an "intermediate" system, makes it possible to better adjust the distribution of customer requests to "CORE" service providers, for example as a function of the loaded configuration (eg number, type and performance of services). Advantageously, an embodiment of the method according to the invention makes it possible to minimize the refusal rate of client requests.
[0005] Advantageously, an embodiment of the method according to the invention makes it possible to control the allocation of computing time to third-party clients in a guaranteed way. Advantageously, an embodiment of the method according to the invention makes it possible always (or almost always) to give a reliable prior answer of acceptance and / or refusal of support of the request, optionally accompanied by a status notification. the quality of service (eg response time, accuracy, reliability) that will result from the calculation. In an alternative embodiment, a FRONTAL server can be implemented on one of the cores, while the other cores have an equivalent partition that hosts a computing resource (for example FRONTAL server on FMC1 and NAVDB SERVER on FMC2). According to another variant, it is also possible to implement a single FRONTAL; the front-end server can interrupt the calculation of a client to pass another (e.g. pause / resume mechanism or "Pause / Resume" in English), to manage priorities (eg vis-à-vis deadlines). Advantageously, according to certain implementations of the invention, the functional cache can make it possible to "smooth" the load of cores CORE; it can be predictive (optionally) but also functional cache on historization. The isolation in one or more different partitions makes it possible to evolve these processes of caching to make them more and more "intelligent" (to confer mechanisms of automatic filling or "auto-completions").
[0006] Advantageously, the methods according to the invention are generally compatible with the notion of AID (for "Domain Interaction Agent"). Instead of scattered clients that go directly to the "server" system, an interface can focus requests and make requests to the services offered by the "server".
[0007] The method according to the invention determines or defines or creates or specifies or defines a "SEP SERVER", which is a functionally separated modulate of the "CORE". For each service, a function of "calculation time" of the service is determined. When said service is solicited by a client to perform a calculation, the method determines the necessary CPU calculation time "without adjustment" and compares it to a response time objective. A calculation time goal is determined so that clients can respond to a given response time (the server can be called by multiple clients, and can also perform its own calculations). The said response time objective can be determined by the client and / or determined by the server. In some variants, the customer has the ability to confirm or cancel the request. Optionally, an embodiment of the method according to the invention can manage the history of commands or recurrent requests (i.e. functional caching).
[0008] Advantageously, an embodiment of the method according to the invention makes it possible to decouple the evolutions of the "CORE" service providers and the "CLIENT" clients, which ensures the upward compatibility and control of the requalification of all the systems. The variability problems of CLIENTS are therefore isolated from those concerning CORE. Customers do not need to know the overall system architecture, the list of available cores or the list of unit services, and their scheduling to perform a query. Everything is supported by the middle layer "SEP SERVER". Advantageously, an embodiment of the method according to the invention makes it possible to manage the variability of the "system of systems". For example regarding customer management: the priorities being managed by the "SERVER FRONT END", different algorithms can be implemented according to customer needs. Advantageously, an embodiment of the method according to the invention makes it possible to retain the intrinsic performance of the "CORE" without having to know the external customers a priori, while guaranteeing the customers in question a calculation result with the quality of service required. By the term "intrinsic performance" is meant or designated performance in terms of CPU and RAM / ROM as well as in terms of reliability (that a given system must fulfill in the context of an architecture posed a priori for meet security requirements and ensure a comprehensive operation). Since this architecture is defined a priori (i.e. with identified services and / or identified data exchanges), it becomes possible to add new interactions without having to modify these services and data. The robustness of the "CORE" remains guaranteed since the algorithms - sometimes complex client management and interface mapping - are managed outside the "CORE", i.e. by the "SEP SERVER". Advantageously, the invention is applicable to any architecture of real-time embedded systems (aeronautics, automotive, medical, etc.) involving a plurality of clients, one or more software applications (for example flight management) and a plurality of units providing services (eg digital "hearts").
[0009] Advantageously, the distributed system according to the invention makes it possible to add new connections (i.e. new "CLIENTS") to the real-time service provider system called "SERVER", by guaranteeing them a quality of service corresponding to the expectations of the client system. Generally a good operation of the overall system is allowed, which does not degrade its performance and does not give rise to software or hardware modifications of said "SERVER". Adding a new client, new service provider, or new connection or client will only result in a requalification of the other 10 clients / servers. The performance of the system of systems is maintained in accordance with the initial requirements. DESCRIPTION OF THE FIGURES Various aspects and advantages of the invention will appear in support of the description of a preferred mode of implementation of the invention, but without limitation, with reference to the figures below: FIG. overall technique of the invention; Figure 2 schematically illustrates the structure and functions of a known FMS flight management system; Figure 3 illustrates the structuring of a system of systems according to the ATA standard; Figure 4 illustrates an example of ATA architecture; FIG. 5 shows an exemplary architecture according to one embodiment of the method according to the invention; FIG. 6 illustrates examples of steps of the method according to the invention; Figure 7 schematically illustrates the structure and functions of an FMS flight management system; Figure 8 illustrates examples of alternative embodiments of the invention.
[0010] DETAILED DESCRIPTION OF THE INVENTION Certain terms and technical environments are defined below. The pilot of an aircraft or aircraft uses the flight plan information in several contexts: within the avionics equipment by means of the FMS (Flight Management System) and / or by means of an "EFB" (Electronic 10 Flight Bag) , for example tablet type. The acronym or acronym EFB corresponds to the English terminology "Electronic Flight Bag" and refers to embedded electronic libraries. Generally translated as "electronic flight bag" or "electronic flight bag" or "electronic flight tablet", an EFB 15 is a portable electronic device and used by flight personnel (eg drivers, maintenance, cabin ..). Different classes of EFB material exist. Class 1 EFBs are portable electronic devices (PEDs), which are not normally used during take-off and landing operations. This device class 20 does not require a particular certification or authorization administrative process. Class 2 EFB aircraft are normally located in the cockpit, e.g. mounted in a position where they are used during all phases of flight. This class of devices requires prior authorization. Class 1 and Class 2 devices are considered portable electronic devices. Class 3 fixed installations, such as computer media or fixed docking stations installed in aircraft cockpits generally require approval and certification by the regulator. 3030 805 11 The acronym or acronym FMS corresponds to the English terminology "Flight Management System" and refers to the flight management systems of aircraft. During the preparation of a flight or during a diversion, the crew proceeds to enter various information relating to the progress of the flight, typically using a flight management device of an FMS aircraft. An FMS comprises input means and display means, as well as calculation means. An operator, for example the pilot or the co-pilot, can enter via the input means information such as RTAs, or "waypoints", associated with waypoints, that is to say points on the vertical of which the aircraft must pass. The calculation means make it possible in particular to calculate, from the flight plan comprising the list of waypoints, the trajectory of the aircraft, as a function of the geometry between the waypoints and / or altitude and speed conditions.
[0011] The acronym HMI stands for Human Machine Interface (HMI). The entry of information, and the display of information entered or calculated by the display means, constitute such a man-machine interface. In general, the HMI means allow input and consultation of flight plan information, flight data, etc. Figure 1 illustrates the overall technical environment of the invention. Avionics equipment or airport means 100 (for example a control tower in connection with the air traffic control systems) are in communication with an aircraft 110. An aircraft is a means of transport capable of evolving within the earth's atmosphere. . For example, an aircraft can be an airplane or a helicopter (or even a drone). The aircraft comprises a cockpit or cockpit 120. Within the cockpit are piloting equipment 121 (so-called avionics equipment), comprising for example one or more on-board computers (means for calculating, memorizing and storing data). data), including an FMS, means for displaying or viewing and data entry, communication means, as well as (possibly) means for haptic feedback. An EFB 122 can be on board, portable or integrated into the cockpit. Said EFB can interact (two-way communication 123) with the avionics equipment 121. The EFB can also be in communication 124 with external computing resources, accessible by the network (for example cloud computing or "cloud computing" 125. In particular, the calculations can be carried out locally on the EFB or partially or totally in the calculation means accessible by the network, the on-board equipment 121 is generally certified and regulated while the EFB 122 and the connected computer means 125 do not are generally not (or to a lesser extent) .This architecture makes it possible to inject flexibility on the side of the EFB 122 while ensuring a controlled safety on the side of the onboard avionics 121. FIG. an FMS with functions described in the ARINC standard Generically, an FMS designates any system or set of systems to manage the route / trajectory aircraft / aircraft (regardless of physical implementation variants). A flight management system within the meaning of the FMS invention can correspond to different hardware and / or software implementations. In the state of the prior art, an FMS currently designates a precise calculator, the perimeter of which is illustrated in FIG. 2. However, other architectures are quite possible: an FMS can correspond to a single server or to a single server. a plurality of servers (working centrally and / or distributed). The expression "at least one server associated with the FMS" generally refers to access to the hardware and / or software resources of the entity for performing the functions described herein.
[0012] An FMS 200 type system is generally disposed in the cockpit 120. The FMS is associated with avionic means 121 and one or more human-machine interfaces 220 comprising input means, for example formed by a keyboard, and means for display, for example formed by a display screen, or simply a touch display screen. An FMS generally comprises the following functions: - Navigation (LOCNAV) 201, to perform the optimal location of the aircraft according to the location-based means 230 such as satellite positioning or GPS, GALILEO, VHF radionavigation beacons, inertial units. This module communicates with the aforementioned geolocation devices; - Flight Plan (FPLN) 202, to capture the geographical elements constituting the "skeleton" of the route to be followed, such as the points imposed by the departure and arrival procedures, the waypoints, the air corridors, commonly designated "airways" according to English terminology. Navigational database (NAVDB) 203, for constructing geographic routes and procedures from data included in the bases relating to points, tags, interception or altitude legacies, etc .; - Performance database, (PERFDB) 204, containing the aerodynamic and engine parameters of the aircraft; Lateral Trajectory (TRAJ) 205, to construct a continuous trajectory 25 from the points of the flight plan, respecting aircraft performance and containment constraints (RNP); Predictions (PRED) 206, to construct an optimized vertical profile on the lateral and vertical trajectory and giving estimates of distance, time, altitude, speed, fuel and wind in particular at each point, at each change of pilot parameter and at destination , which will be displayed to the crew. The disclosed methods and systems primarily affect or concern this portion of the calculator. - Guidance (GUID) 207, to guide the aircraft in its lateral and vertical planes on its three-dimensional trajectory, while optimizing its speed, using the information calculated by the Predictions function 206. In an aircraft equipped with a device automatic pilot 210, the latter can exchange information with the guide module 207; - Linking digital data (DATALINK) 208 to exchange flight information between flight plan / predictions functions and control centers or other aircraft 209. - one or more screens, including so-called FMD, ND and VD screens. From the flight plan defined by the pilot (list of waypoints called "waypoints"), the lateral trajectory is calculated according to the geometry between the crossing points (commonly called LEG) and / or altitude conditions and speed (which are used for calculating the turning radius). On this lateral trajectory, the FMS flight management system optimizes a vertical trajectory (in altitude and speed), passing through possible constraints of altitude, speed, time. Figure 3 illustrates the structuring of a system of systems according to the ATA (acronym for "Air Transport Association") standard, according to the practices of aircraft manufacturers. Each real-time avionics system is architectured and developed to meet performance requirements (in terms of RAM, ROM, failure rate, CPU and functional QoS) determined in a defined framework of use. In this architecture, each system is connected to other systems. Each system consumes data and services made available by these other systems and produces data and services for other systems. These systemic interactions are typically statically defined when developing the overall "system of systems" architecture, i.e. when allocating operational functions to the different physical systems making up the overall system. Thus, it is common in the avionics world to have several dozen systems that meet all the functions of the aircraft. Typically, aircraft operations are allocated to the systems according to a logical structuring, defined in the normative document of the "Air Transport Association" (ATA). The ATA 300 system includes chapters 310 for grouping aeronautical systems in headings. Figure 3 provides examples of such chapters 310 as well as their names in English 320 and French 330. The different names are common to the various aeronautical stakeholders such as engineering, maintenance and maintenance, pilots as well as for flight manuals (and generally for all aircraft manufacturers). Thus, the aircraft architecture comes in collaborative avionics systems, each with a specific function, and interactions with other systems to make the operational service expected. These functions are distributed over several physical computers, according to the specific choices of the different aircraft manufacturers, in order to guarantee the performances. Embedded systems are qualified, with a demonstrated level of performance, for a given environment. The guarantee of the overall functioning of the "system of systems generally results from a so-called" worst case "analysis (the systems are loaded to the maximum and the functioning of the operation is checked with respect to operational requirements). Statistical techniques can also be used. In these techniques, "black box" type analyzes can be conducted concerning for example the effect of the response times of each system on the overall operational performance, aiming at a probability of failure lower than one or more predefined thresholds. In the aeronautical field, for example, there are thresholds of occurrence of an operation having catastrophic consequences (i.e. with loss of human life) at 10 ^ -9 per hour of flight. These probabilistic techniques make it possible to assign to each system the requirements in terms of response time and the probability of keeping these requirements, so as not to exceed the threshold probability of 10 ^ -9.
[0013] Figure 4 illustrates an example of ATA architecture. Different ATAs are distributed on physical systems (calculators), for example 411, 412 and 413. The interactions between systems are defined a priori during the development of the general architecture, and the systems are developed and adjusted to meet the strict need the interactions, ie the customers of a system are well identified, the industrials develop the functions allocated to their system, which are in conformity with the performances expected in the framework of strict employment defined a priori: in other words, all the Customers are known and no new customers can interact with the system without requalification of the whole. In this systemic framework, the probability of non-performance of each system is specified, to ensure that the probability of non-performance of the overall performance remains below a predefined security threshold. Type 400 boxes are network hubs (called "switches" in the so-called ARINC653 version of the aircraft network). All the computers (for example 411 and 412) are connected to a "switch" (e.g. usually with redundancy reasons for availability) and interact with other computers on the network (eg 413). A technical problem is that the addition of a new system to a given "system of systems" can lead to costly requalification (it is necessary to demonstrate again that overall operating performance is maintained and reallocate the performance of "server" systems), even when no new service is expected by the "server" system.
[0014] FIG. 5 shows an exemplary architecture according to one embodiment of the method according to the invention. In the example that is illustrated the service provider "SERVER" split in two: a) a "SEP SERVER" 510 intermediate between client systems called "CLIENTS" (501, 502, 503) and one or more systems or hearts of calculation of unitary services called "CORE" (522,524). The unit service calculation cores are intended to guarantee the intrinsic performance of the "CORE" (ie to ensure that the "CORE" mission is kept out of the "CUSTOMERS"), while granting customers computing resources with a high quality. guaranteed service and also guaranteeing the independence of the development cycles between the "CUSTOMERS" and the "CORE". The "SEP SERVER" 510 system is an adaptive system, according to different schemes. It can be configurable "at design time" at "start time" and / or "at runtime". The term "at design time" means that the number of customers, the times and the associated services are determined at the time of design. This approach has limitations in terms of maintenance and scalability. At start time, the expression "at start time" means that the system reads a configuration table, for example "SERVER BDD" that describes the topology of the customers present, and reads the list of available "CORE" services (with their characteristics). . The expression "at runtime" means that the method further comprises one or more steps aimed at satisfying one or more clients and / or the associated adaptation mechanisms (for example in real time).
[0015] In an alternative embodiment, in order to guarantee the intrinsic performance of the "CORE" system, it may be defined a "field of use" in which the configuration may be authorized. In general, the "SEP SERVER" is a system that self-configures to reserve the necessary resources. In particular embodiments, the configuration of the "SEP SERVER" may result from external actions. According to one aspect of the invention, a "SEP SERVER" is isolated from "CORE" and this "SEP SERVER" is configured by establishing in particular one and / or the other of the following analyzes: terms of unit service quality of the services offered by the "CORE", ii) the correspondence between the requests of the "CUSTOMERS" and the unitary services of the "CORE" capable of executing them; iii) the correspondence between the results of the CORE unit services and the results expected by the client; iv) the scheduling of the requests of the various "CUSTOMERS" on the "CORE" (s) able to process them; y) management of a functional cache to keep the results estimated as potentially reusable over a long period. In an alternative embodiment (optional), the "SEP SERVER" 510 20 comprises two separate elements: 1) a "SERVER FRONT END" 513 (which may also be called "FRONTAL"); this server manages the incoming flows of client requests (priority, filtering, feasibility of the calculation in the desired QoS) and requests the "SERVER CORE" or the "CORE" and 2) a "SERVER CORE" 514 (which can also be called "WRAPPER"); this server, in the case of complex requests, transforms the requests into "batch" of IDD services (521 for the CORE 1 522) of the "CORE" and orders the execution of said IDD services on the "CORE". The advantage of this variant of implementation lies in isolating the variability between the "prioritization" technology of the clients (who can use complex logic and algorithms) and the "interface management" part. In situations where customers directly use the "CORE" service list, this "SERVER CORE" is not necessary.
[0016] In the example of FIG. 5, a client 1501 makes a request 5011 which is received by the FRONTAL server 513 and then sent to SERVER CORE 514 (after verification of its eligibility, for example via a database 515, which consolidates data. including for example: the CPU time of the unitary services (including the Server), a matrix or service query / batch tables, a service data formatting matrix, a list of execution resources (eg by request, with precedence, independence , parallelization, etc.), one or more customer priorities, etc.). SERVER CORE 514 then appropriately addresses one or more IDD services (for example, "service 1" 5211 which solicits CORE 1 522 for example via access to the list of IDD unit services 521). At the output, the response of the Service 1 5221 is returned to the SEP SERVER (first CORE responses 512 then the responses of the FRONTAL 511) and finally the answer 1 is returned to the client 1 501.
[0017] FIG. 6 illustrates examples of steps of the method according to the invention. In a first step 610, the cores (CORE) are configured. In general, this step consists in structuring the "SERVER BDD" element 515. The configuration can be done in advance or "Offline" by an operator (for example, according to the CORE and Client core configuration, as known from the overall architecture of the system). In "Plug and Play" embodiments, the "SEP SERVER" can read at startup, for example on the embedded system network, the list of cores "CORE" and their characteristics in terms of quality of service (QoS), so to structure in real time the configuration file of the "SERVER BDD". In a first sub-step 6.1, the method can create a first table "T_CORE" containing the list of digital cores "CORE" "Ki" (i = 1 .. nb_core) service providers. In a particular embodiment, nb_core may be equal to the value 1. In other embodiments the variable nb_core is strictly greater than the value 1. In a second substep, for each "CORE" Ki, the method can create a second table "T_Ki_Services" containing the list of unit services "S (Ki, j) offered by the core Ki, j = 1 .. nb_services (Ki). In an alternative embodiment, a matrix can be determined, which matrix comprises the cores Ki according to one dimension and the services S according to another dimension. Other mathematical formalization are possible.
[0018] In a third sub-step, for each service S (Ki, j), the method creates a QoS table "Quality of service" T_Qos_S (Ki, j), of said unitary service S (Ki, j), a function of the capacities of the core Ki . For example, said table may contain the heart CPU characteristics such as the time available by MIE for the service S (ki, j). Optionally, the QoS table may include the core RAM / ROM memory characteristics for the S (ki, j) service. Optionally, the QoS table can include the computational accuracy characteristics for the service S (ki, j) (including for example the number of iterations for the iterative computations, the integration step for the numerical integrations, thresholds for tolerancing calculations, quality of basic mathematical libraries, precision of floats used, etc.). These characteristics can be fixed (static) or parameterizable (the QoS is then variable). Optionally, the QoS table may include characteristics relating to the reliability of the calculation (such as the development level of the computer hosting the "CORE"). For embedded real-time systems, this reliability can for example materialize under the acronym "DAL" defined by the RTCA D01 78B standard, which makes it possible to know the probability of failure of a calculation chain (ex: level C = 10A -5 / hour, level = 10 ^ -7, level B = etc). Reliability can be expressed as the erroneous calculation probability for each service S (Ki, j). Moreover, the services of the "CORE" accessible to customers being qualified since they are generally part of the embedded code, Quality of Service can be defined a priori especially for aspects of accuracy and reliability of calculations (depth of integrations,. ..), for the aspects associated with the response times and for the aspects associated with the available memory for the client (number of calculated elements). In a second step 620, the requests of the "CLIENTS" are configured. In a first sub-step, the method creates a client request table "T_requêtes" which factors the requests R (k) (k = 1, nb_requêtes) of the different clients C (m) (m = 1 .. nb_clients). This step can be carried out previously offline by an operator, for example after analyzing the different requests requested by the customers. In a "Plug and Play" alternative, the "SEP SERVER" can read at startup, on the network of the embedded system, the list of "CLIENT" clients and their characteristics in terms of requests in order to structure in real time the configuration file of the "SERVER BDD". In a first embodiment, the table contains the requests R (k) regardless of the structure of the clients. A new client can then advantageously connect and use existing queries, without modifying the SERVER BDD configuration file. In an alternative embodiment, for each request R (k), the table can associate the clients C (m) that use it. A matrix can be determined, for example.
[0019] Advantageously, the SEP SERVER statically knows at startup the list of potential customers, and therefore all possible requests; it can also manage variable priorities and "packages" depending on the customer. In a second substep, for each request, the method creates a correspondence matrix Req_Serv, between the client operational requests and a batch of unit services "S (*, j)" offered by the service providers "CORE" (the notation "*" indicates that the correspondence does not depend on the heart but on the typology of unitary services). In a "single-core" environment, the matrix therefore contains the correspondence between each client complex request R and the succession of services S (K1, j) to be executed to carry out the request. In a "multi-core" environment, the query can advantageously be distributed over several cores, to take advantage of the parallelism, for example, or the fastest cores. The matrix S also contains the order of execution of the services to carry out the request R (k). For each request R (k), the method determines the commands COM (S (*, j), n) n = 1 for the service to be executed first. In one embodiment, an identical "n" value for 2 services of a request means that they are parallelizable. In a particular embodiment, the matrix contains only a list of "simple" requests corresponding to the unitary services (bijection). This allows CLIENTS to access the unitary services of the heart directly. In one embodiment, the matrix contains the list of "simple" requests corresponding to the unitary services and the list of complex requests corresponding to a batch of unitary services. This variant allows CLIENTS to access core unit services and perform complex queries. This variant is advantageously flexible. For single unit services, the "CUSTOMERS" themselves use the available unit services via the first step to manage their requests, not by direct service call (ie to manage the variability of the cores) but by calling a request intermediate reformatted thanks to the matrix REQ_SERV. For complex queries, the server knows and executes the "batch" of unit services. This approach avoids several disadvantages and limitations (no update of customer code when unitary services vary, no need to know the functioning of the cores (ie of what functionally realizes the service) nor of the dynamics of the service. how do these cores work (ie what is the permitted sequence of unit services, which data to reuse / modify from one unit service call to another call, etc.).
[0020] In a third substep, for each request, the method creates a client response structure matrix T_Rep (R (i)), containing the list of expected values at the output. In one embodiment, the unit data (from the control batch of the second substep) are simply filtered and formatted (units, floating point format, rounding, etc.). In one embodiment, the unit data from the command batch are processed mathematically to reconstruct the response. The processing may include arithmetic, trigonometric, functional, or logical operators. These rules will be used later to format the response to the client. In an alternative embodiment, the method creates a matrix comprising the cores Ki on one dimension and the services S on another dimension and the QoS on the other dimensions, and the correspondence matrix on other dimensions. Other mathematical formalization is possible (functions instead of tables for example).
[0021] In a third step 630, the "SEP SERVER" processes requests from "CLIENTS". In a first substep, a request R (i) of a "CLIENT" C (k) is received by the "SEP SERVER". The "SEP SERVER" (or its "SERVER FRONT END" part) analyzes the support of the request. If it is not part of the list of managed queries, stored in the T_Query table of the "SERVER BDD" 515 then an error message can be communicated as well as a notification of rejection of the request of the client. Optionally, if the client is not declared or if the request is not authorized for this client, the request may be rejected, for example in the context of a T_requests table containing the requests and the clients. Optionally, a variant embodiment can implement a client "package" mechanism (eg similar to the operation of a blocked phone plan): if a customer has consumed all his requests over a given time, a rejection notification can be issued . Optionally, an alternative embodiment may implement a mechanism for filtering clients on-service consumers in consideration of one or more predefined thresholds). For example, if a client makes more than N queries over a given time interval, one or more rejection notifications can be issued. Optionally, in an alternative embodiment, if the maximum number of queries manageable or manipulable by the "SEP SERVER" is reached (request stack R1, Rmax), the request R (i) can be rejected (otherwise, the request will be accepted ).
[0022] In a first alternative substep (variant embodiment), use is made of the "functional cache" consultation: if the data expected by the client is available and still valid, the other steps are not performed and the method is continues directly to the fifth step. The functional cache can be a "predictive cache": it contains data computed periodically by the "SEP SERVER" (i.e. without client solicitation, for example based on the analysis of recurring requests). The functional cache can also be a "cache of history": it can keep in memory some results of queries already executed, as long as they are not obsolete, to be able to immediately return the result to a client which would make the same request a little later. In a second sub-step, the "SEP SERVER" (or its "SERVER FRONT END" part) queries the "SERVER BDD" to determine the correspondence or "mapping" in English between the request R (i) and the batch of services units of the heart (s) "S (*, j) thanks to the matrix REQ_SERV. In a third sub-step, the "SEP SERVER" (or its "SERVER FRONT END" part) interrogates the SERVER BDD for the list of cores "CORE 1" ... "CORE N" which are able to execute at the same time. least one of the services (and / or use of the functional cache look-up (in the same manner as described above)), in a fourth sub-step, the "SEP SERVER" (or its "SERVER FRONT END" part). ") Interrogates the SERVER BDD to know the Quality of Service (in particular the response time of each core for each service) It deduces the response time of the request which is the sum of the response times of the unitary services on the heart Tu (S (k, j), K (k)), and the processing time of the "SEP SERVER" Tu (R (i), SEP SERVER) itself after having also counted the response time of the requests already waiting on this heart Optionally, for parallel services in a multi-core environment ", The calculated response time subtracts the response time of the parallelizable services (for 2 parallelizable services, the longest service time is selected). In an alternative embodiment, the "SERVER CORE" is responsible for reducing the response time by performing parallel calculations during execution. Optionally, in a "multi-cceurs" environment, the "SERVER FRONT END" can optimize the response time by choosing the cores that respond the fastest, for example according to the Quality of Service in response time required. In an alternative embodiment, the "SERVER CORE" is responsible for reducing (e.g., even more) the response time by choosing the cores, during execution. Optionally, in a "single-core" environment, if the QoS of the services is configurable, the FRONTAL can determine a unit QoS to respond to a global QoS of the request (in terms of accuracy, reliability, limit response time, etc.). Based on the results (i.e. by comparing the achievable QoS and the required QoS), the "SERVER FRONT END" can accept or reject the request. In a fifth (optional) sub-step, the "SEP SERVER" (or its "SERVER FRONT END" part) can reconsider the current requests present in the processing stack, to take into account a request whose response time does not fit. not (or no longer) within the time limits provided that this reconsideration does not contravene the time limits associated with other requests. In an alternative embodiment, the management of the request processing can provide, for example to manage an RI request, if time and / or resources are available, the insertion of a request R2 in the processing queue (provided the limit execution time of R1 is respected). In a sixth substep (optional), if the "SERVER FRONT END" is separate from the "SERVER CORE", the "SEP SERVER" (or its "SERVER FRONT END" part) sends the request R (i) to the "SERVER FRONT END". SERVER CORE ". In an alternative embodiment, the six substeps of the third step 630, the "SERVER FRONT END" manages the request / services correspondence and the execution of the services to the FMS in place of the "SERVER CORE". In this option, the "SERVER FRONT END", the "SERVER CORE" and the "SEP SERVER" correspond to one and the same entity. In a seventh (optional) substep, the "SEP SERVER" can interact with the functional cache. In this way, part of the substeps are performed autonomously (and quickly) for a certain number of requests, for example due to the provision of recurrent data and / or often requested by the customers. Query monitoring can be done at startup, or by capitalizing queries that are called over time. If a request is frequently requested (or requested by several clients), the seventh sub-step then performs the said request, either periodically or on CORE event. The data is made available in the fifth step and subscribing CUSTOMERS can be notified of the update. In one embodiment, the periodicity of the request, in the absence of events, can be performed according to a criterion of obsolescence of the data. Such obsolescence parameters can be embedded in the "SERVER BDD" for each unit service and can result in a "timer" or other physical business parameter (such as the evolution of altitude or distance traveled for an airplane). The functional cache feature can be applied to other services, such as database lookups (possibly with sorting and filtering operations). In a fourth step, the "SEP SERVER" commands the cores "CORE" to execute the queries. In a first sub-step, the "SEP SERVER" (or its "SERVER CORE" part) calls the various K (k) cores identified with their unit services S (k, j) in the form of a batch of COM commands ( S (k, j), n). Optionally, for services that can be parallelized in a multi-core environment, the calculated response time subtracts the parallel service response times (for two parallel services, the longest service time is cut).
[0023] In an alternative embodiment, the "SERVER FRONT END" which is responsible for determining the parallelization, and then transmits the order of calculations and the list of cores in COM (S (k, j), n) form to "SERVER CORE" ". Optionally, in a "multi-cceurs" environment, the "SERVER CORE" optimizes the response time by choosing the cores that respond the fastest, according to the Quality of Service in response time required. In an alternative embodiment, the "SERVER FRONT END" is responsible for reducing the response time by selecting the cores during execution. In a second sub-step, the "SERVER CORE" retrieves the data structures resulting from the responses Rep_unitaire (S (K, j), n) and stores them in a storage means Rep_CORE 512. In a third substep, the "SERVER CORE" warns the "SERVER FRONT END" when the batch of COM commands is finished and makes available the result of the commands in Rep_CORE.
[0024] In a fifth step, the "SEP SERVER" processes the result of the requests. In the case of using a functional cache, some of the steps can be avoided (in particular, by copying one or more previous results). In an alternative embodiment, a result may be associated with an expiry date (or not). in a first sub-step, the "SEP SERVER" (or its "SERVER FRONT END" part) retrieves the structures made available by the third sub-step of the fourth step, in the Rep_Core database 512. In a second substep , the "SEP SERVER" (or its "SERVER FRONT END" part) retrieves the response structures expected by the client for the request R (i) in the table T_Rep. in a third sub-step, the "SEP SERVER" (or its "SERVER FRONT END" part) calculates the responses in the "Client" format Rep (R (i)) by applying the rules of the third substep of the second step. In a fourth sub-step, the "SEP SERVER" (or its "SERVER FRONT END" part) fills the data structure "Response Server for Ri" 511 and warns the client of the availability of the data of the response. In a fifth substep, the "SEP SERVER" (or its "SERVER FRONT END" portion) is notified by the client that the request has finished being processed. If multiple clients subscribe to the request, they are notified. In a sixth substep, the "SEP SERVER" 510 (or its "SERVER FRONT END" portion) 513) requests the reset of the base of the WRAPPER 514 and the "Response Server for Ri" data structure 511. The figure 7 schematically illustrates the structure and functions of a Flight Management System (FMS). The method according to the invention is advantageously applicable to said FMS. The FMS can be considered a "SERVER". According to the ATA architecture, the "flight management" or FMS is part of the "navigation" and concerns chapters ATA 22 and ATA 34. 10 In the aeronautical sense, navigation systems consider and ensure the location (eg position, status , speed, etc.), the "Flight Planning" (eg reference route, terminal procedures, waypoints, taxiing, etc.), trajectory, guidance, steering (algorithms to optimize the mission, choice of diversion airports , Etc.) Figure 7 schematically represents an FMS. To ensure its mission, the FMS is connected to many other computers (a hundred). In the architecture according to the method, the FMS as described above includes a "FMS CORE" which provides a list of 20 consultation / modification unit services and a "FMS SERVER" which performs the tasks of "SEP SERVER" "Of the process (eg query mapping, CORE FMS isolation, CORE FMS service execution control," results processing, etc.). The FMS server 710 comprises, for example, unitary FMS services 25 which can be classified into three main categories of service (AEEC standard ARINC 702A): 1) the geographical data consultation services 720 ("navigation data & dynamic magnetic variation"), for example, NAV DB 721 and MAG VAR 722, which allow customers to search for geographic information (NAV DB) or magnetic declination on a point in the world; 2) the aircraft performance performance consulting services 730 ("aircraft characteristic & performances") involving TRAJ, PRED and PERF DB 731 for example; and 3) the "flight management" services 740 ("flight management") for example the consultation of the state of the aircraft 741 (eg position, speed, states of the systems connected to the FMS, such as the state engines , etc.), the consultation and modification of the flight and flight plan 742 and the consultation and modification of the flight 743 initialization data (eg capture of take-off speeds, cruise altitude, forecast weather, 10 fuel consumption modes, etc.) Examples of "CLIENT" requests are described below. Future operations in the aircraft require (more and more) third-party systems interact with the FMS, using existing public services and / or using existing private services (to be made public 15 ie visible) and / or using new services to implement in the FMS. By way of example of such third-party systems, it is possible to cite, for example, a) the initialization of the FMS flight plan by an external computer (of the "Electronic Flight Bag" type of touchpad or EFB), b) the integration of the "flight plan" of the FMS with the "running plan" of the ground taxi calculator; c) the optimization of the mission (for example called by a ground client (eg company tool for example) or on board (eg tablet, EFB) via FMS calculation requests (alternative flight plans FPLN diversion, alternatives of FMS optimization parameters, alternative FMS initialization parameters eg 25 take-off weight test) d) FMS software update (especially its 28-day cycle Navigation databases) by third-party equipment (tablet, maintenance tool, EFB); e) the use of FMS requests by a traffic field monitoring system, the weather to filter alerts, or confirm them, or optimize lateral and vertical adjustments (eg: avoidance of a moving cloud mass detected by Weather Radar) by systems such as TCAS, TAWS, GPWS, WxR or WIMS; f) the use of FMS requests to help trigger events on a third-party system (eg RMS); g) the verification of conformity of the lateral and / or vertical trajectory calculated by the FMS, compared with the digitized aeronautical charts provided to the crew (stored in a tablet, an EFB for example); h) the use of the FMS system to know predictions over a given time horizon according to modes of conduct of the flight (guidance) and aircraft state defined; i) interaction with the Flight Warning System (FWS); J) Passengers connected via their cabin interface (IFE for In Flight Entertainment), wishing to know the predictions in time, speed for their destination; k) the use of the FMS via an AID (Domain Interaction Agent) or an integrated IHS (Human Interface System) which concentrates and organizes exchanges between computers; I) the use of the FMS by any of the above clients, including HMI and DATALINK for local or predicted geographic data (waypoints, airports, radio navigation beacons); m) interactions with HMI and DATALINK, etc. Thus, a wide variety of new customers are likely to interact with the FMS (EFB, WIMS, TCAS, TAWS, WxR, PA, FQMS, IFE), or most systems according to different ATAs. In addition, two additional categories of customers usually interact with the FMS system: Man Machine Interfaces (HMI) that allow operators (crew) to interact with the FMS and the interface called CMU 25 (for "Communication Management Unit") which allows a ground operator (airline, air traffic control) to interact with the FMS. This CMU calculator is for example a client of the FMS data and it can request the modification of the mission (i.e insert "revisions" in the FMS). By the term "interaction" is meant sending a request to the FMS, 30 with an expected return, as opposed to the term "information" which corresponds to the fact that third party systems subscribe to periodically issued data - or on event - by the FMS. Some requests correspond to unitary services ("1 for 1"). For example: a request for recovery of airports around the aircraft, corresponding to a unit service "Get_Airport" of the navigation service of the navigation database; a request to insert a company Route in the format AEEC ARINC 424 for example, for a customer is also a unit service "INSERT_COROUTE" offered by the part "Flight Preparation"; a request for consultation of the airplane status (current fuel for example) corresponds to a unit service Get_current_Fuel offered by the "Aircraft States" part); a request to consult the current flight envelope of the aircraft corresponds to a unit service Get_flight_envelope offered by the part "Flight envelope Computation" More complex requests can generate "batches" (or sequences or sets or collections, ordered or no, prioritized or not) of requests. For example an "INSERT FPLN" request to insert a separate element flight plan, as currently performed by the DATALINK services for companies (AOC) and control centers (ATC), defined in the ARINC 702A standards. for AOC and D0258 for ATC can include or correspond to a plurality of requests and / or parameters associated with these requests. The insertion of a complete flight plan may correspond to an "INSERT FPLN" request which generally includes the following parameters: a) elements allowing the calculation of the route to be followed (eg airports, take-off procedures, etc.) b) elements of initialization of the flight plan, allowing in addition to the calculations of trajectory and predictions (eg cruise level, expected take-off mass, etc.) and c) environmental elements on the flight plan (eg forecast weather along the flight plan, barometric setting etc.). The INSERT FPLN client request may include a set of parameters, sometimes in an undifferentiated manner. The role of the SERVER will then be to determine the unit services to respond to the request and the order in which the commands must be processed.
[0025] In a conventional FMS, constraints exist in terms of scheduling of the different unit services (e.g. insertion of the departure procedure only after inserting the departure airport). Some FMS, by their architecture and their design, have counter-intuitive rules (some FMS allow for example unitary services of insertion of an airport of departure alone, then the insertion of other elements while others FMS still impose to insert the airport of departure AND the arrival airport in advance to any other insertion of lateral and vertical element, etc.). Similarly, some FMS allow the entry of initialization elements without having entered a route, while others impose it beforehand. Some FMS allow to link unitary insertion services of airways, and automatically manage crossings between two successive airways while others prohibit it, etc ... Advantageously, the SEP SERVER allows to adapt and Manage unit orders in the correct order to respond to requests. The SEP SERVER can also make comparisons between different alternatives for optimization purposes. For example, a complex query may consist of comparing diversion alternatives along the flight plan. Each "diversion" constitutes a flight plan in its own right. The role of the SEP SERVER will then be to chain the requests of this type into "INSERT FPLN" type requests for each alternative of diversion, each request of the "INSERT FPLN" type giving rise to a batch of unitary services as proposed in the following table. previous example. At the output, the fifth sub-step of the fourth step can use logical operators to make such comparisons (eg time and fuel predicted for arrival, search for better flight level depending on the weather, etc.). The periodic updating of information in the form of a functional cache 5 can take into account the position of the aircraft (updated when this position evolves according to predefined thresholds) and / or at predefined time intervals (regular, periodic, etc. Figure 8 illustrates examples of alternative embodiments of the invention. The interactions between the elements of the architecture can be unidirectional or bidirectional. The different graphs corresponding to the different possible architectures can be oriented, ordered, open, closed, cyclic, acyclic, etc. In particular, the different front-end servers and / or calculation cores can interact in different ways, for example directly or indirectly. In a particular embodiment, a FRONTAL C AB 800 server can call another FRONTAL AB 811 server, which can then address several cores 812 and 813 for example. The FRONTAL C AB 800 thus indirectly addresses the cores 812 and 813. The front end C AB 800 may also be in direct interaction with a CORE C 820. In an alternative embodiment, a FRONTAL server may be common to several cores. Conversely, in an alternative embodiment, the same core can be addressed by several FRONTAL type servers. More generally still, portions of the graph or circuits may be redundant, so as to obtain robust and / or responsive distributed systems. In one embodiment, a SERVER comprises a plurality of entities or applications selected from the list comprising FMS, HMI, IHS, AID, CMU, TCAS, TAWS, WIMS, WxR, EFB, tablet, FQMS, PA, FWS, IFE, TAXI or a dedicated generic partition and a CLIENT may include an entity or an application other than the (ie different from) SERVER. In one embodiment, a SERVER may include one or more of NAV DB, PERF DB, FPLN, TRAJ, PRED, GUID, LOCNAV, DATALINK, or the HMI, and a CLIENT may include an entity or application other than the (ie different from) SERVER.
[0026] Embodiments are described below. There is disclosed a method for managing the flight of a computer-implemented aircraft within a flight management system or FMS, the method comprising the steps of receiving a request issued by at least one client; determining a correspondence between the request and one or more predefined unitary services executable by at least one server associated with said FMS; thread the specified unit service (s) in one or more queues; determine a response time associated with the request; and notify said at least one client of the response time.
[0027] The method according to the invention defines a system of segmenting a request into several parts or portions or sub-requests or unit requests (eg with or without recovery) each corresponding to unitary flight management services (eg ATA services, confer -after). Unit services are parallelized, i.e. are queued. From this distributed system, a response time associated with the client's request is determined (according to different techniques, see below). The client is notified or informed of the processing of his request according to different modalities (e.g. actual existence of the treatment and / or predictable duration and / or actual duration and / or duration and level of quality of service etc.).
[0028] The definition of unit services (i.e. terminal granularity, "atomic" level) generally allows pooling and / or merging and / or simplifying and / or aggregating requests from different clients. In this case, downstream calculations are actually optimized or at least optimizable (eg caching can reduce calculations). It is usually possible to pool processing resources and / or inputs. In other words, it is possible to pool the i.e. computing resources as well as to pool the i.e. request by assimilating queries, in whole or in part. In concrete terms, requests can be optimally allocated to available hardware resources (e.g., different calculation cores), for example to smooth or spread the load. In a development, the step of determining a response time comprises a step of determining the processing time of each unit service, the processing time of a unit service being a function of the occupation of one or more several queues. In one embodiment, a theoretical or simulated time may be calculated or simulated. In one embodiment, the actual response time, i.e. resulting from measurements conducted on the computation cores can be determined. Depending on the embodiments, the determination of the response time may be different. For example, the response time may be a function of i) the processing time of the unitary services Sj (for example recovered from the "SERVER BDD") and ii) the occupation of the processing queue T by requests in progress. 'execution. More generally, within a distributed system (elements implemented in parallel), the estimate of the response time may depend on the processing queue of the queries being executed. In one variant, the "SERVER FRONT END" calculates the response time of the request on the basis of the processing time of the unitary services Sj (recovered from the "SERVER BDD") and the occupation of the processing queue T by queries running. The "SERVER CORE" receives the services to be executed S (i, j) from the FRONTAL and their associated processing queue, and the cores K on which to execute the services Si. In one development, the method further comprises a step consisting in perform the specified unit services. The "SEP SERVER" can command the execution of the "Services" S (i, j) at "CORE", on said processing queue T, via the commands COM (S (i, j), n) in a development, the method further comprises a step of communicating a response to a client, said response comprising the results of the execution of the unitary services. In a development, at least one client is associated with a processing priority. QoS schemas can exist with or without the client priority management. Some customers may have pre-defined priorities, for example by default, others may never be associated with such priorities, others may be given priorities over time (for example, depending on expectations already elapsed, depending on the client's criticality in the overall systemic perspective, etc.). In a development, the step of determining a match between said request and one or more predefined unit services and / or the step of threading the one or more unit services into one or more queues and / or The step of executing said determined unit services is a function of the priority associated with said client. In this case, the priority associated with a client (eg predefined, determined or allocated) can influence a number of process steps: a priority can for example modify the processing within a queue (eg request in "Doubling" another or interrupting another etc). Alternatively or cumulatively, a priority can drive or influence the execution of one or more unitary services (e.g. level of precision more or less extended). In particular, the execution scheduling of the unit services can be controlled (in whole or in part) by priority parameters associated with the clients (if any). Always alternatively or cumulatively, a priority can determine or influence the partition of an initial request into a bundle of unit requests (the granularity can optionally be a function of the client's criticality in the overall system, this criticality being partially reflected or "contextualized" via the priority level, at least in some embodiments). In a development, a priority is dynamic. The priority parameters can be predefined in whole or in part.
[0029] They can be static (that is to say for example invariant over time) or dynamic (that is to say for example depend on the overall load of the system of systems, depending on the arrival of new customers etc.). In one embodiment, the "SEP SERVER", for example implementing the determination of the unitary services in correspondence with the request initially received and the queues, is configured by establishing in particular one and / or the other the following analyzes: (i) the characteristics in terms of the unitary quality of service offered by the "CORE", (ii) the correspondence between the requests of the "CLIENTS" and the unitary services of the "CORE" (s) capable of executing them; iii) the correspondence between the results of the CORE unit services and the results expected by the client; iv) the scheduling of the requests of the various "CUSTOMERS" on the "CORE" (s) able to process them; y) management of a functional cache to keep the results estimated as potentially reusable over a long period. In a development, a priority associated with a client is further associated with an absolute maximum number of requests and / or a maximum number of requests for a predefined time interval and / or parameters with respect to accuracy and / or reliability. execution of unitary services. Quality of service management (view by transforming the initial request into a plurality of unitary services, queue management, etc.) can be static but also dynamic (i.e. evolving over time). Moreover, this quality of service can be controlled or controllable in various ways (it can in particular be configured and / or configurable). According to one aspect of the invention, the management of the quality of service can be refined in different ways. For example, in the context of prioritizing some customers over others, a number of additional parameters may be taken into account. For example and optionally, the management of the QoS (for example through the management of a table or matrix defining or associated with this QoS) can take into account the characteristics (or parameters) in terms of RAM / ROM memory and processor load (e.g., core for a service S (ki, j).) Optionally, such a QoS table may also include the features of computational accuracy, or even characteristics relating to the reliability of the service. calculation According to another aspect of the invention, the "SEP SERVER" comprises a storage means (SERVER BDD), which determines the number of requests "R max" acceptable input, a list of requests "R (i)", the response structure Rep (R (i)) for each request R (i), the required response time (deadline) "T_R (i)" per request "R (i)", the list of cores "K (i ) "Attackable by the server, the list of services" S (*, j) "offered, the typology of services offered (list of the cores that offer the service, parallelizable, sequential, order), the QoS of each unit service of the core and the execution times of the CORE k (i): Tu (Si, Kj), and the server 5 SERVER : Tu (Ri, Server) (data formatting, server internal processing times ...). The SERVER BDD includes the REQ_SERV correspondence matrix of the unit services corresponding to each Request. The SERVER BDD determines a correspondence between the processing times of the services S (*, j) and the processing times 10 of the requests R (i), on the basis of the correspondence table REQ_SERV. It is underlined that the computation T (Ri) = f (T (S1), T (Sn)) is not a simple sum (considering the parallelizable treatments). According to one aspect of the invention, it is possible to implement a customer "package" mechanism (eg for example analogous to the operation of a blocked phone plan): if a customer has consumed all his requests over a given time, a notification rejection can be issued. Optionally, an alternative embodiment may implement a mechanism for filtering clients on-service consumers in consideration of one or more predefined thresholds). For example, if a client makes more than N queries over a given time interval, one or more rejection notifications can be issued. Optionally, in an alternative embodiment, if the maximum number of requests manageable or manipulable by the "SEP SERVER" is reached (request stack R1, Rmax), the request R (i) can be rejected. In some embodiments, the "SEP SERVER" system 510 is an adaptive system, according to different schemes. It can be configurable "at design time" at "start time" and / or "at runtime". The term "at design time" means that the number of customers, the times and the associated services are determined at the time of design. This approach has limitations in terms of maintenance and scalability possibilities. At start time, the expression "at start time" means that the system reads a configuration table, for example "SERVER BDD" that describes the topology of the customers present, and reads the list of available "CORE" services (with their characteristics). .
[0030] The expression "at runtime" means that the method further comprises one or more steps aimed at satisfying one or more clients and / or the associated adaptation mechanisms (for example in real time). In a development, the request and / or one or more queues are associated with one or more caching.
[0031] According to one embodiment, the caching can take place before or after queuing. The caching may relate to the client's (initial) request and / or the unit requests derived from said initial request (the granularity of the caching may be variable). Caching can also affect the execution of unit services. There may be a plurality of caches (for example of different natures or of the same nature for reasons of redundancy and speed of access). In one embodiment, the "SERVER FRONT END" makes requests to "SERVER CORE" in the absence of a client request, to manage a functional cache.
[0032] In a development, caching is predictive. The use of a "functional cache" can be used: if the data expected by the client is available and still valid, the other steps are not performed and the process can proceed directly.
[0033] In one embodiment, the functional cache is a "predictive cache": it contains data calculated periodically by the "SEP SERVER" (without client request, ie in the absence of a client request, for example depending on the analysis of recurrent requests).
[0034] In a development, cache (caching) is historization. The functional cache can be a "cache of history": it can keep in memory some results of queries already executed, as long as they are not obsolete, to be able to immediately return the result to a client who would make the same request a little later. In other words, the results of a query are stored to a certain extent in case another client (or the same) resumes an equivalent query, and the results are still valid. Depending on the context, the data manipulated in the cache may for example be data comprising recurring requests of the same type (offline or online), data relating to the phase of the flight, data relating to connected equipment, data relating to the dynamics of the aircraft, data relating to the state of the systems, data relating to the obsolescence of these same data etc.
[0035] In a development, the processing of one or more queues may be interrupted and / or resumed. In one aspect of the invention, the processing of requests by the CORE on a processing queue T can be interrupted and then resumed ("Pause / Resume"). The triggering of such interrupts or queues can be controlled by various entities. In one embodiment, the control is centralized (e.g., by one or more queues, ie a unit in charge of scheduling calculations). In other embodiments, the control is distributed: the client-server model (eg "master-slave") can be made more sophisticated insofar as at least some clients can interact with each other (competition, coopetition, etc.) eg via queues and / or priority management. Finally, embodiments can be hybridized and include centralized controls in parts while other controls result from the emergence of interacting parts of the system. The criteria for or causing these interruptions and resumptions may also be different; they can in particular take into account the priorities associated with the customers or be controlled by a "dispatcher" operating according to predefined rules.
[0036] In a development, the response to a client's request is formatted in a format adapted for said client from the formats associated with the unitary services. The response to the query includes the results of unit service execution. Because these unit services are "isolated" or decoupled from the evolution of the customers, the raw data provided by the core services must generally be reprocessed (or modified or translated or manipulated or transformed or complemented or filtered) in order to meet the needs of the customers. clients. According to one aspect of the invention, the "SERVER FRONT END" can format or "reformat" ie "translate" the response Rep (Ri) to the request R (i), from the structures Rep_unit (S (*, j )) recovered from the "SERVER CORE" during the execution of the services S (Ï) The "reformatting" or more generally "translation" operation can notably comprise various logical operations (eg unit or data conversions data fusion, arithmetic operations, the application of algorithms or rules etc.) For example, an EFB (customer) may wish to know the best route among a set of N routes, with the fuel consumed and the time needed to reach the known destination. The EFB client 25 queries the FMS "CORE" via the "SERVER" by sending its N Routes. The "SERVER FRONT END" takes into account his request. "SERVER CORE" uses the services of "CORE" and returns N routes using the "FLIGHT PREPARATION" service; this service allows you to insert a route into the FMS. Then for each route, the "SERVER FRONT END" retrieves in the "Core Response" the raw response of the service in the format of "CORE", namely a 3D trajectory containing 2D segments (ground trace) and predictions at altitude , speed, time of passage, weather and fuel on each element of the road. In order to allow the customer to compare the alternatives (eg classification of routes by fuel and time), the "SERVER FRONT END" extracts the data for each of the routes, and creates a table containing for each route the fuel consumed and the time to reach the destination. In a development, a query is associated with a response time objective and / or a limit response time. The request sent by a client may be accompanied by information relating to the processing constraint (eg "what the customer wants", optimal delay) and / or the future acceptability of a response (eg "what the customer accepts in return, "maximum delay). In general, according to one aspect of the invention, the acceptability of a new request R (i) can be determined, based on the response times of the request R (i), compared to a time objective. Answer. In one embodiment, by determining one or more response times lower (or higher) than one or more predefined thresholds, it is also possible to effectively handle the "small" queues (for example, if the priorities are equivalent). A computing time goal is determined so that customers can respond to a given response time (the server can be called by multiple clients, and can also perform its own calculations). The said response time objective can be determined by the client and / or determined by the server. In a development, several received requests are determined to be at least partially identical.
[0037] Input requests can be completely identical (identical or nearly identical requests) or partially redundant (considering matching unit services). Queries can be determined as identical (eg binary copies), similar (eg identical in terms of their essential characteristics, ie different on non-critical points), "equivalent" (ie interpreted as such according to a predefined model, eg functionally equivalent). In some very particular embodiments, however, it may sometimes happen that the same request is transformed into unit service sets which may be different. As a result, the possibilities of pooling several requests can be modified. In a development, the priority associated with a customer results from a voting mechanism. In one embodiment, the clients and / or the servers behave as a peer-to-peer (peer-to-peer) network. In particular, the priority allocated to each node can "emerge" as a result of negotiations conducted in and by the network. In a development, one or more queues are distributed queues. In one embodiment, the management of a queue is on a "first in, first out" (FIFO) basis. In queuing, distributed architectures can also be implemented (e.g. "distributed queues"). The scheduling rules can then include "priority queuing" algorithms (prioritizing certain types of traffic, letting only low priority traffic pass if there is no more high priority traffic), "Custom queuing" (according to weighted round-robin algorithms, aiming for example to pass client requests, in turn, leaving more time for priority packages) or even "fair queuing" (eg assign successively and equitably a possibility for customers to put their queries), etc. In a development, at least one client can cancel a request.
[0038] In one embodiment, a client can contribute to the core services economy if it turns out that it no longer needs a result (eg it can voluntarily lighten downstream calculations and core services can be adapted to the recognition of such end or retrieve commands).
[0039] In a development, a client can authenticate (e.g. strong authentication). In a secure embodiment of the invention, access to core services can be encrypted and / or authenticated. In a development, the server is associated with a flight management system or FMS.
[0040] The FMS SERVER comprises a "SERVER CORE" which receives the requests from the FRONTAL and their associated processing queue, and the cores K on which to execute the services Sj. The "SERVER CORE" associates with each client request, the list of "FM services", on the basis of the correspondence table between a client request and a list of "FM SERVICES". The "SERVER CORE" commands the execution of the "FM Services" COM (S (*, j), n) to "FM CORE" on said processing queue T. The "SERVER CORE" provides the "SERVER FRONT END" the Rep_init results (S (1)) of the execution of the "FM SERVICES". In a development, a unitary service being an ATA type avionics service (system and method characteristic). A computer program product is disclosed, said computer program comprising code instructions for performing one or more steps of the method when said program is run on a computer. There is disclosed an avionics flight management system of an aircraft comprising means for performing one or more of the steps of the method. In a development, the system comprises at least one server (CORE) associated with the flight management system FMS and at least one client server (SEP SERVER), said at least one server (CORE) associated with the FMS comprising calculation units or cores, each computing unit or core capable of executing a plurality of unit services, and said at least one client server (SEP SERVER) capable of receiving one or more requests issued by one or more clients. In a development, the client server (SEP SERVER) comprises a front-end server (FRONTAL) receiving the unit services and determining the processing queues of the unit services and further comprising a calculation server (CORE) for executing said unit services. In a development, said server (CORE) queries a database server (SERVER BDD) which includes the list of unit services per computing unit. In a development, a unitary service is an ATA type avionics service. The present invention can be implemented from hardware and / or software elements. It may be available as a computer program product on a computer readable medium. The support can be electronic, magnetic, optical or electromagnetic. The means or computing resources can be distributed ("Cloud computing").

权利要求:
Claims (27)
[0001]
REVENDICATIONS1. A method for managing the flight of a computer-implemented aircraft within a flight management system or FMS, comprising the steps of: - receiving a request issued by at least one client; determining a correspondence between the request and one or more predefined unitary services executable by at least one server associated with said FMS; 10 - put the unit service (s) determined in one or more queues; - determining a response time associated with the request; and notify said at least one client of the response time. 15
[0002]
2. The method of claim 1, the step of determining a response time comprising a step of determining the processing time of each unit service, the processing time of a unit service being a function of the occupation of one or more queues. 20
[0003]
The method of any of the preceding claims, further comprising a step of executing said determined unit services. 25
[0004]
The method of claim 3, further comprising a step of communicating a response to a client, said response comprising the results of the execution of the unitary services.
[0005]
The method of any of the preceding claims, wherein at least one client is associated with a processing priority.
[0006]
The method of claim 5, the step of determining a match between said request and one or more predefined unit services and / or the step of threading the one or more unit services into one or more queues and or the step of executing said determined unit services according to the priority associated with said client.
[0007]
7. The method of claim 5, a priority being dynamic. 10
[0008]
The method of claim 5, wherein a client-associated priority is further associated with an absolute maximum number of requests and / or a maximum number of requests for a predefined time interval and / or precision parameters and / or or reliability of performance of the 15 unitary services.
[0009]
9. Method according to any one of the preceding claims, the request and / or one or more queues being associated with one or more caching.
[0010]
The method of claim 9, wherein caching is predictive.
[0011]
11. The method of claim 9, caching being historization.
[0012]
A method according to any one of the dependent claims, wherein the processing of one or more queues can be interrupted and / or resumed. 30
[0013]
The method of claim 4, wherein the response to a client request is formatted in a format adapted for said client from the formats associated with the unitary services. 20 25
[0014]
The method of any of the preceding claims, wherein a request is associated with a response time objective and / or a limit response time.
[0015]
15. Method according to any one of the preceding claims, several received requests being determined to be at least partially identical.
[0016]
16. The method of claim 5, the priority associated with a client resulting from a voting mechanism.
[0017]
The method of any one of the preceding claims, wherein one or more queues are distributed queues. 15
[0018]
The method of any one of the preceding claims, wherein a client can cancel a request.
[0019]
19. A method according to any one of the preceding claims, a client that can authenticate. 20
[0020]
20. Method according to any one of the preceding claims, the server being associated with a flight management system or FMS.
[0021]
21. A method according to any one of the preceding claims, a unitary service being an ATA type avionics service.
[0022]
22. A computer program product, said computer program comprising code instructions for performing the steps of the method of any one of claims 1 to 21 when said program is run on a computer.
[0023]
An aircraft flight management avionics system comprising means for performing one or more of the steps of the method according to claims 1 to 21.
[0024]
24. System according to claim 23, comprising at least one server (CORE) associated with the flight management system FMS and at least one client server (SEP SERVER), said at least one server (CORE) associated with the FMS comprising units. computing or cores, each computing unit or core can execute a plurality of unit services, and said at least one client server (SEP SERVER) can receive one or more requests issued by one or more clients.
[0025]
25. System according to claim 24, the client server (SEP SERVER) comprising a front-end server (FRONTAL) receiving the unitary services and determining the processing lines of the unitary services and further comprising a calculation server (CORE) for executing said services. unitary services.
[0026]
26. The system of claim 25, said server (CORE) querying a database server (SERVER BDD) which comprises the list of unit services per computing unit.
[0027]
27. System according to any one of claims 23 to 26, a unitary service being an avionics service type ATA. 25

类似技术:

---

公开号 | 公开日 | 专利标题

---

EP2945062A1|2015-11-18|Method for performing services in real time, in particular flight management and real-time system implementing such a method

---

FR3030805A1|2016-06-24|QUALITY OF SERVICE OF A FLIGHT MANAGEMENT SYSTEM

---

EP2991274B1|2017-02-01|Method for performing services in adaptive real time, in particular flight management and real-time system implementing such a method

---

FR3055958A1|2018-03-16|DECISION AID FOR THE REVISION OF A FLIGHT PLAN

---

FR3013831A1|2015-05-29|AVIONIC SYSTEM OF AN AIRCRAFT

---

US8700298B2|2014-04-15|Tailored arrivals allocation system clearance generator

---

FR3021401A1|2015-11-27|RECONFIGURATION OF THE DISPLAY OF A FLIGHT PLAN FOR THE PILOTAGE OF AN AIRCRAFT

---

FR3046273A1|2017-06-30|OPEN ARCHITECTURE FOR FLIGHT MANAGEMENT SYSTEM

---

FR3067802A1|2018-12-21|ALTERNATIVE ROAD MANAGEMENT FOR AN AIRCRAFT

---

EP3712762A1|2020-09-23|Methods and systems for generating and recommending api mashups

---

US10889297B2|2021-01-12|Determining a safe driving speed for a vehicle

---

US20180293687A1|2018-10-11|Ridesharing management for autonomous vehicles

---

EP3340208A1|2018-06-27|Management of messages to flight crews

---

FR3048773A1|2017-09-15|METHOD AND SYSTEM FOR MANAGING A MULTI-DESTINATION FLIGHT PLAN

---

FR3067801A1|2018-12-21|METHOD AND SYSTEM FOR AIDING THE FLIGHT MANAGEMENT OF AN AIRCRAFT IN TERMS OF OPTIMIZATION OF THE OPERATIONAL COSTS OF THE AIRCRAFT

---

FR3038750A1|2017-01-13|METHOD FOR INTEGRATING A NEW NAVIGATION SERVICE IN AN OPEN AIR ARCHITECTURE OPEN ARCHITECTURE SYSTEM OF A CLIENT-SERVER TYPE, IN PARTICULAR A FIM MANUFACTURING SERVICE

---

WO2019082046A1|2019-05-02|Real-time identification and provision of preferred flight parameters

---

FR3082829A1|2019-12-27|AIRCRAFT MANAGEMENT

---

FR3038751A1|2017-01-13|METHOD FOR INTEGRATING A CONSTRAINED ROAD OPTIMIZATION APPLICATION IN AN OPEN ARCHITECTURE AIRCRAFT SYSTEM OF CLIENT-TYPE SERVER

---

US11200517B2|2021-12-14|Redistribution based on real time presence data

---

FR3083897A1|2020-01-17|SYSTEM FOR MANAGING THE TASKS OF AN AIRCRAFT CREW DURING A MISSION AND ASSOCIATED METHOD

---

FR3072795A1|2019-04-26|METHOD FOR CONTROLLING THE ALERT RETRIEVAL | AND / OR SYSTEM RECONFIGURATION PROCEDURE |, COMPUTER PROGRAM PRODUCT AND SYSTEM FOR CONTROLLING THE SAME

---

US10760915B2|2020-09-01|Synchronizing nodes at a meeting point

---

US10791183B1|2020-09-29|Managing contact while navigating

---

US20220068125A1|2022-03-03|Autonomous vehicle management based on object detection

同族专利:

---

公开号 | 公开日

---

US20160182687A1|2016-06-23|

---

FR3030805B1|2016-12-23|

---

US10523785B2|2019-12-31|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

US5657450A|1995-11-15|1997-08-12|Xerox Corporation|Method and apparatus for time estimation and progress feedback on distal access operations|

---

WO2003029968A1|2001-09-29|2003-04-10|Siebel Systems, Inc.|Method, apparatus, and system for implementing view caching in a framework to support web-based applications|

---

EP2600682A1|2010-09-08|2013-06-05|ZTE Corporation|Method, system and treminal for user plane location and location server|

---

US6339772B1|1999-07-06|2002-01-15|Compaq Computer Corporation|System and method for performing database operations on a continuous stream of tuples|

---

US6317659B1|1999-12-09|2001-11-13|Honeywell International Inc.|Layered subsystem architecture for a flight management system|

---

US6574750B1|2000-01-06|2003-06-03|Oracle Corporation|Preserving consistency of passively-replicated non-deterministic objects|

---

US8082491B1|2000-05-09|2011-12-20|Oracle America, Inc.|Dynamic displays in a distributed computing environment|

---

US6625618B1|2000-12-15|2003-09-23|Tsunehiko Arai|Maintenance manual interface system and medium containing a computer program product thereof|

---

US20030088434A1|2001-08-02|2003-05-08|Elaine Blechman|Web-based clinical, cross-organizational management information system & method of centralizing & coordinating treatment referrals for persons in need of supervision|

---

US7222148B2|2002-05-02|2007-05-22|Bea Systems, Inc.|System and method for providing highly available processing of asynchronous service requests|

---

US8332473B1|2005-05-02|2012-12-11|American Airlines, Inc.|System and method for managing multiple message format communication|

---

US7418531B2|2005-05-04|2008-08-26|Pillar Data Systems, Inc.|Quality of service for data storage volumes|

---

US20070174529A1|2005-12-29|2007-07-26|Intel Corporation|Queue manager having a multi-level arbitrator|

---

US8832302B1|2006-03-31|2014-09-09|Rockwell Collins, Inc.|System and method for a priori scheduling of network services|

---

US8381214B2|2006-05-05|2013-02-19|Microsoft Corporation|Extensible job submission|

---

US20080070218A1|2006-08-30|2008-03-20|The Boeing Company|System, method, and computer program product for delivering a training course|

---

US8312464B2|2007-08-28|2012-11-13|International Business Machines Corporation|Hardware based dynamic load balancing of message passing interface tasks by modifying tasks|

---

US8255631B2|2008-02-01|2012-08-28|International Business Machines Corporation|Priority-based prefetch requests scheduling and throttling|

---

WO2009140786A1|2008-05-19|2009-11-26|Telefonaktiebolaget Lm Ericsson |Handling enum queries in a communication network|

---

US8321569B2|2009-12-17|2012-11-27|International Business Machines Corporation|Server resource allocation|

---

US9037880B2|2012-06-15|2015-05-19|Infosys Limited|Method and system for automated application layer power management solution for serverside applications|

---

US10223327B2|2013-03-14|2019-03-05|Fisher-Rosemount Systems, Inc.|Collecting and delivering data to a big data machine in a process control system|

---

US9088501B2|2013-07-31|2015-07-21|Citrix Systems, Inc.|Systems and methods for least connection load balancing by multi-core device|

---

GB2518158A|2013-09-11|2015-03-18|Ibm|Method and system for data access in a storage infrastructure|

---

US9984158B2|2014-03-18|2018-05-29|Axis Ab|Finding services in a service-oriented architecture network|

---

US20150372717A1|2014-06-18|2015-12-24|Qualcomm Incorporated|Slotted message access protocol for powerline communication networks|

---

US10560542B2|2014-09-15|2020-02-11|Ge Aviation Systems Llc|Mechanism and method for communicating between a client and a server by accessing message data in a shared memory|

---

US9471229B2|2014-12-15|2016-10-18|Avago Technologies General Ip Pte. Ltd.|Scaling performance for raid storage controllers by predictively caching data for host write requests|US10684933B2|2016-11-28|2020-06-16|Sap Se|Smart self-healing service for data analytics systems|

---

FR3074007B1|2017-11-21|2019-10-18|Thales|METHOD OF TRANSMITTING A DATA MESSAGE TO A RECEIVER ELECTRONIC DEVICE, TRANSMITTER ELECTRONIC DEVICE AND COMPUTER PROGRAM THEREOF|

---

US10991255B2|2018-04-05|2021-04-27|Ge Aviation Systems Llc|Providing an open interface to a flight management system|

---

US10854091B2|2018-07-03|2020-12-01|Honeywell International Inc.|Energy management visualization methods and systems|

---

US10992745B2|2019-05-13|2021-04-27|Verizon Patent And Licensing|Method and system for lifecycle management of application services at edge network|

法律状态:
2015-11-23| PLFP| Fee payment|Year of fee payment: 2 |

---

2016-06-24| PLSC| Publication of the preliminary search report|Effective date: 20160624 |

---

2016-11-28| PLFP| Fee payment|Year of fee payment: 3 |

---

2017-11-27| PLFP| Fee payment|Year of fee payment: 4 |

---

2019-11-28| PLFP| Fee payment|Year of fee payment: 6 |

---

2020-11-25| PLFP| Fee payment|Year of fee payment: 7 |

---

2021-11-26| PLFP| Fee payment|Year of fee payment: 8 |

优先权:

---

申请号 | 申请日 | 专利标题

---

FR1402933A|FR3030805B1|2014-12-19|2014-12-19|QUALITY OF SERVICE OF A FLIGHT MANAGEMENT SYSTEM|FR1402933A| FR3030805B1|2014-12-19|2014-12-19|QUALITY OF SERVICE OF A FLIGHT MANAGEMENT SYSTEM|

---

US14/975,135| US10523785B2|2014-12-19|2015-12-18|Quality of service of a flight management system|